<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Replication FAQ</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="rep.html" title="Chapter 12.  Berkeley DB Replication" />
    <link rel="prev" href="rep_partition.html" title="Network partitions" />
    <link rel="next" href="rep_ex.html" title="Ex_rep: a replication example" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 11.2.5.3</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Replication FAQ</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 12. 
		Berkeley DB Replication
        </th>
          <td width="20%" align="right"> <a accesskey="n" href="rep_ex.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="rep_faq"></a>Replication FAQ</h2>
          </div>
        </div>
      </div>
      <div class="orderedlist">
        <ol type="1">
          <li>
            <p>
            <span class="bold"><strong>Does Berkeley DB provide support for
            forwarding write queries from clients to
            masters?</strong></span>
        </p>
            <p>
            No, it does not.  

     
    
            In general this protocol is left entirely to the application.
            Note, there is no reason not to use the communications channels
            a Base API application establishes for replication support to forward
            database update messages to the master, since Berkeley DB does
            not require those channels to be used exclusively for
            replication messages.  Replication Manager does not currently
            offer this service to the application.
        </p>
          </li>
          <li>
            <p>
        <span class="bold"><strong>Can I use replication to partition my
        environment across multiple sites?</strong></span>
    </p>
            <p>
        No, this is not possible.  All replicated databases must be equally
        shared by all environments in the replication group.
    </p>
          </li>
          <li>
            <p>
        <span class="bold"><strong>I'm running with replication but I don't see my databases
        on the client.</strong></span>
    </p>
            <p>
        This problem may be the result of the application using absolute
        path names for its databases, and the pathnames are not valid on
        the client system.
    </p>
          </li>
          <li>
            <p>
        <span class="bold"><strong>How can I distinguish Berkeley DB messages from application messages?</strong></span>
    </p>
            <p>
        There is no way to distinguish Berkeley DB messages from
        application-specific messages, nor does Berkeley DB offer any way
        to wrap application messages inside of Berkeley DB messages.
        Distributed applications exchanging their own messages should
        either enclose Berkeley DB messages in their own wrappers, or use
        separate network connections to send and receive Berkeley DB
        messages.  The one exception to this rule is connection information
        for new sites; Berkeley DB offers a simple method for sites joining
        replication groups to send connection information to the other
        database environments in the group (see <a class="xref" href="rep_newsite.html" title="Connecting to a new site">Connecting to a new site</a> for more information).
    </p>
          </li>
          <li>
            <p>
        <span class="bold"><strong>How should I build my <span class="bold"><strong>send</strong></span> function?</strong></span>
    </p>
            <p>
        This depends on the specifics of the application.  One common way
        is to write the <span class="bold"><strong>rec</strong></span> and <span class="bold"><strong>control</strong></span> arguments' sizes and data to a
        socket connected to each remote site.  On a fast, local area net,
        the simplest method is likely to be to construct broadcast
        messages.  Each Berkeley DB message would be encapsulated inside an
        application specific message, with header information specifying
        the intended recipient(s) for the message.  This will likely
        require a global numbering scheme, however, as the Berkeley DB
        library has to be able to send specific log records to clients
        apart from the general broadcast of new log records intended for
        all members of a replication group.
    </p>
          </li>
          <li>
            <p>
        <span class="bold"><strong>Does every one of my threads of control on
        the master have to set up its own connection to every client?
        And, does every one of my threads of control on the client have
        to set up its own connection to every master?</strong></span>
    </p>
            <p>
        This is not always necessary.  In the Berkeley DB replication
        model, any thread of control which modifies a database in the
        master environment must be prepared to send a message to the client
        environments, and any thread of control which delivers a message to
        a client environment must be prepared to send a message to the
        master.  There are many ways in which these requirements can be
        satisfied.
    </p>
            <p>
        The simplest case is probably a single, multithreaded process
        running on the master and clients.  The process running on the
        master would require a single write connection to each client and a
        single read connection from each client.  A process running on each
        client would require a single read connection from the master and a
        single write connection to the master.  Threads running in these
        processes on the master and clients would use the same network
        connections to pass messages back and forth.
    </p>
            <p>
        A common complication is when there are multiple processes running
        on the master and clients.  A straight-forward solution is to
        increase the numbers of connections on the master — each
        process running on the master has its own write connection to each
        client.  However, this requires only one additional connection for
        each possible client in the master process.  The master environment
        still requires only a single read connection from each client (this
        can be done by allocating a separate thread of control which does
        nothing other than receive client messages and forward them into
        the database).  Similarly, each client still only requires a single
        thread of control that receives master messages and forwards them
        into the database, and which also takes database messages and
        forwards them back to the master.  This model requires the
        networking infrastructure support many-to-one writers-to-readers,
        of course.
    </p>
            <p>
        If the number of network connections is a problem in the
        multiprocess model, and inter-process communication on the system
        is inexpensive enough, an alternative is have a single process
        which communicates between the master and each client, and whenever
        a process' <span class="bold"><strong>send</strong></span> function is
        called, the process passes the message to the communications
        process which is responsible for forwarding the message to the
        appropriate client.  Alternatively, a broadcast mechanism will
        simplify the entire networking infrastructure, as processes will
        likely no longer have to maintain their own specific network
        connections.
    </p>
          </li>
        </ol>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="rep.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="rep_ex.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Network partitions </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Ex_rep: a replication example</td>
        </tr>
      </table>
    </div>
  </body>
</html>
